scm cli: lots of exceptions after changing Xmx in scm.ini
Hi,
When I used scm cli to commit changes to a workspace, I got java/lang/OutOfMemoryError. So I changed Xmx to 1024m in scm.ini. The directory to be checked in is around 25G. Then when I tried to check in again, I got a bunch of exceptions on console 
Any suggestions what happened? Thanks Lin |
6 answers
Your sandbox was corrupted by the exception. Run 'scm repair'.
e |
|
Hi thanks for your reply.
I got out of memory error again when running scm repair !ENTRY org.eclipse.osgi 4 0 2010-06-07 15:44:15.957 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: java.lang.OutOfMemoryError at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(Unknown Source) at com.ibm.team.filesystem.cli.core.internal.Application.start(Unknown Source) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Unknown Source) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Unknown Source) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Unknown Source) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.eclipse.equinox.launcher.Main.invokeFramework(Unknown Source) at org.eclipse.equinox.launcher.Main.basicRun(Unknown Source) at org.eclipse.equinox.launcher.Main.run(Unknown Source) Caused by: java.lang.OutOfMemoryError at com.ibm.team.internal.repository.rcp.streams.UnsynchronizedBufferedInputStream.<init>(UnsynchronizedBufferedInputStream.java:36) at com.ibm.team.internal.repository.rcp.streams.UnsynchronizedBufferedInputStream.<init>(UnsynchronizedBufferedInputStream.java:28) at com.ibm.team.internal.repository.rcp.dbhm.DiskBackedHashMap.readObject(DiskBackedHashMap.java:382) at com.ibm.team.internal.repository.rcp.dbhm.DiskBackedHashMap$Entry.getValue(DiskBackedHashMap.java:938) at com.ibm.team.internal.repository.rcp.dbhm.CachedDiskBackedHashMap$CachedEntry.getValue(CachedDiskBackedHashMap.java:292) at com.ibm.team.internal.repository.rcp.dbhm.DiskBackedHashMap.get(DiskBackedHashMap.java:160) at com.ibm.team.filesystem.client.internal.SharingMetadata2.getFileItemInfo(Unknown Source) at com.ibm.team.filesystem.client.internal.MetadataChangeTracker.getInverseInfo(Unknown Source) at com.ibm.team.filesystem.client.internal.MetadataChangeTracker.getLocalChanges(Unknown Source) at com.ibm.team.filesystem.client.internal.localchanges.LocalChangeTracker.refreshPendingChanges(Unknown Source) at com.ibm.team.filesystem.client.internal.localchanges.LocalChangeTracker.access$0(Unknown Source) at com.ibm.team.filesystem.client.internal.localchanges.LocalChangeTracker$LocalChangesComputer.runRecompute(Unknown Source) at com.ibm.team.filesystem.client.internal.localchanges.LocalChangeTracker$LocalChangesComputer.rejoin(Unknown Source) at com.ibm.team.filesystem.client.internal.localchanges.LocalChangeTracker.syncChanges(Unknown Source) at com.ibm.team.filesystem.client.internal.localchanges.LocalChangeManager.refreshSynchronously(Unknown Source) at com.ibm.team.filesystem.client.internal.localchanges.LocalChangeManager.doRefresh(Unknown Source) at com.ibm.team.filesystem.client.internal.localchanges.LocalChangeManager.refreshChanges(Unknown Source) at com.ibm.team.filesystem.client.internal.operations.SynchronizeOperation.refreshChanges(SynchronizeOperation.java:529) at com.ibm.team.filesystem.client.internal.operations.SynchronizeOperation.synchronize(SynchronizeOperation.java:492) at com.ibm.team.filesystem.client.internal.operations.RebuildCFAOperation.rebuildCFA(RebuildCFAOperation.java:485) at com.ibm.team.filesystem.cli.client.internal.subcommands.RepairCmd.run(RepairCmd.java:96) at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.run(Unknown Source) at com.ibm.team.filesystem.cli.core.internal.SubcommandLauncher.doStart(Unknown Source) ... 14 more I increased xmx to 2048m in scm.ini, but then I got the following error: JVMJ9VM015W Initialization error for library j9gc23(2): Failed to instantiate heap; 2G requested It worked when xmx was set to 1024m. Anybody knows what's wrong here? Thanks. Your sandbox was corrupted by the exception. Run 'scm repair'. |
|
I am not sure whether this relates to the memory usage of my machine.
Here is the current info of my machine on XP Total Physical Memory: 4096MB Available Physical Memory: 1.74GB Total Virtual Memory: 2.00GB Available Virtual Memory: 1.96GB Page File Space: 5.34GB |
|
It looks like your sandbox is corrupt to the point where it can't be repaired. Delete it and reload.
e |
|
Thank you very much for all the reply.
Found the reason of instantiation of heap error: jdk1.5 allows around 1.45GB heap size max. But xmx 1024m gives me out of memory error when checking in from command line. Is it possible to run "scm checkin" to check in 25G files? Thanks. Lin
|
I understand that you are putting the code into the RTC repository for the first time.
You might want to split the 25G into multiple smaller chunks and try scm checkin. Else, you might want to try the following approach that we tried and tested. Our codebase was of 3 Gig. We used the RTC-eclipse client to achieve the checkin. 1) Create an eclipse project and import the elements(that need to be checked in) into this project 2) Load this eclipse project into a workspace repository 3) You can view the imported elements in the "Pending Changes" viewlet. 4) Check in all 5) Deliver all Hope this helps. Thank you very much for all the reply.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.